Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/lists/gem/l_1199/823

Internet Message Format | 1994-08-27 | 11KB

Date: Sun, 17 Jul 1994 13:08:34 -0400 (EDT)
Date: Wed, 13 Jul 94 00:45 EST
Subject: Gem List (fwd)
Subject: Gem List
Subject:  Re: Gem List (fwd)
Subject:  Digest
Subject:  Re: Gem List (fwd)
Date: Sun, 17 Jul 1994 13:08:34 -0400 (EDT)
Mime-Version: 1.0
Precedence: bulk

Forwarded message:
>From [e-mail] Wed Jul 13 04:50:13 1994
Date: Wed, 13 Jul 94 00:45 EST
From: "Daniel J. Hollis" <[e-mail]>
To: ems <[e-mail]>
Subject: Gem List
Message-Id: <10940713054501/[e-mail]>

TO: [e-mail]
Subject:  Re: Gem List (fwd)

Chris:
------
> From the sound of the following flame-bait, you have no idea how object-
> oriented programming works.

An attempt at dodging the question, eh? Hmm, typical.

I have worked with obj
ect-oriented programming on the Atari, and I can say
it's not hard.  Also, I am writing a GUI library in which I am *DESIGNING*
my own object oriented design.  So don't tell me that I have no idea that I
don't know how to do OOP, because I can tell you th
at I do.

> Nothing is a pain with GEM++...  ;-)

Okay, you tell me a *single* command that lets you do sliders without having
to handle it yourself.

> OOP is mainly customizing objects for your own use, once the library is
> finished, that is.

Customi
zing objects for your own use... spending time piecing a library
together to do simple things, rather than having a library pre-written
which 'does it all for you'?

Sounds like some of us enjoy re-inventing the wheel.

> Warwick built GEM++ from scratch,
 so he did all the hard work.  Now if _I_
> use GEM++ for a dialog-in-a-window or something, it takes about 5 lines of
> code.

Ooh, so I guess it's the *best* library out there from the way you speak?
In WinLIB PRO, dialog-in-a-window takes all of 3 line
s of code. But from the
way you're talking, I guess 5 lines of Gem++ code to support
dialog-in-a-window must mean it's better or something?

The three lines of code required in WinLIB PRO are:

int TitleDispatcher(WINDOW *win, int msg_buf[8])
{
    return FA
LSE;
}

WCreateWindow(W_DIAL, 0, NAME|CLOSER|MOVER, "Title dial", NULL,
              -1, EDIT1, -1, TitleDispatcher, 0, -1, -1, -1, -1, editdial,
               D_SWITCHABLE);
WDoDial(NULL);

There. That was really difficult wasn't it? Now with the new w
indow installed,
it WinLIB PRO handles the dialog, lets you move it, BACKGROUND click buttons
with the LEFT mouse button (and not some LAME left-right button simultaneous
click, I might add) and close it. WinLIB PRO handles everything for you when
you ret
urn a FALSE in the window dispatcher code.

> I don't have to do anything special to
> the dialog in the RSC editor, and the code I _do_ write for my dialog
> is exactly what I'd have to write for a normal dialog... something to
> figure out what switches
 were set, what exit button was pushed, etc.

Gheez, like that's hard to code or something? So how do you set an
'active slider' in Gem++ without using special code (since you said you
don't write any special support code for it) and without doing anythin
g
special to the RSC with a RSC editor (ooh mommy, changing the extended
object type is soooo hard!)

> That's a "feature" of not having an up-to-date RSC editor that can build
> RSC objects for the new AES.  If they'd built one of those, adding the
> hie
rarchical menus in a saner way would've been easy.

Yes, but now that there are editors available to do this, then it should not
be too hard to do this... let's see... any number of PD resource editors have
been able to change extended object types for YE
ARS now. Of course, it seems
that some people are living in the past, using obsolete tools (maybe you? :-)

> And possibly a complete re-build of your entire application so you can
> use the new extended-GEM library headers and link it with the new librar
y.

Not so. To change a WinLIB PRO object from a normal slider to an active
slider requires *no* code changes, just a dip into the RSC file to change
the extended object type. You can design entire heirarchical menus in the RSC
editor without having to to
uch a line of code. Can the same be said of Gem++?

>From the consistent evasions of my questions, it's obvious you know nothing
about extended object types. (And yes, I fully expect you will dodge this
statement with yet more doublespeak).

> I guess you'
ve never compared the GUI code for an *application* using GEM++
> to that built with a "normal" library...

That's true. Because there *ARE* no applications written using Gem++.

> 1) They're afraid of GNU C/C++, since it's not a commercial product.

Wron
g. I have no problems with using PD compilers. The reason I stay away
from Gnu C/C++ is that I don't have the resources to waste (i.e. tons of RAM,
and tons of diskspace). And the fact that Gnu C++ spits out binaries roughly
5 to 20 times bigger than the
*same code* in Pure C.

> 2) There's no commercial C++ implementation for the Atari.

So?  The Atari's dead, anyway.

> 5) Their ST is too damn slow for C++ development.

I think you answered your own question there. Not everyone has a TT. Or
even a Falco
n030. Reason #5 is why everyone is using C!

> 6) Their ST doesn't have enough RAM for C++ development (it gets _really_
>    tight in 4M of RAM).

That's exactly the main reason why I shy away from using any type of C++ on
the Atari ST, because of the EN
ORMOUS resource requirements.

A Boeing 747 (Gnu C++) may be able to carry the most passengers at once,
but it's not necessarily the best choice for all pilots. Some of us are
perfectly happy with our small, speedy, agile F-15's (Pure C). :-)

> 7) Their
ST doesn't have a hard drive (!), which is pretty necessary
>    for GNU C/C++, since the compiler is over a meg in size.

Tell me ONE person who isn't a programmer and is sane enough NOT to use a
hard drive. Despite the fact that development is quite pos
sible with
PureC and floppies, and quite impossible with GnuC++ and floppies. :-)

--Ken Hollis (Bitgate Softwate)
-----
Subject:  Digest

> Your code only works if the event loop includes a timer event of very small
> duration. In which case it slows it
 down by having this code running regularly.
> Fine in a single-tasking system, but it will slow down background tasks.

No, it works even if the event loop is very large, too. It's just much
slower :-)

Background tasks are *meant* to be less responsive
than the foreground
task. Otherwise there would be no distinction between the two. :-)

> Why would you want to make a new broadcast message? And I can't think of any
> reason for a new wind_set/get mode.

Who said anything about a new broadcast message?
 IF you wanted to create your
own broadcast message, you should register it so other programmers knew how
to use them.

> it really does replace the aes. It doesn't, however replace the kernel.

Wrong.  It doesn't replace the AES.  Geneva, like Let 'em Fl
y, hooks AES
calls on to the already made AES calls, and intercepts existing routines.
That's why Geneva behaves like it does, and has the limitations it does.

Of course, had you actually bothered to CHECK this before spewing that
statement out, you coul
d have saved yourself the humiliation of being WRONG.

Better yet, break out a debugger and check things out for yourself. You DO
know how to use an assembler-level debugger do you not?

> Since it is cooperative multitasking how can you say it gives one
application
> 25% or 50% of the CPU time anyway?

>From experience, and extensive testing. Two things which you seem to have
little of.
-----
Subject:  Re: Gem List (fwd)

Warwick:
--------
>>>If you use a 1-pixel rectangle, then EVERY mouse movement goes
 back to
>>>your program, and your program has to do an objc_find, EVERY TIME.
>>We're not using "1 pixel rectangles" like you seem to enjoy saying alot :-)
>>You can get the current mouse pointer coordinates by any method you like --
>>as you will see i
n the example code, that part was specifically left "open".
>1-pixel rectangles is the most efficient method.  Of course, your code
>would probably have a 0ms timer event!  Horror of horrors!  [do you use
>MTOS?]

I've use